home *** CD-ROM | disk | FTP | other *** search
/ Apple Developer Connection 1998 Fall: Game Toolkit / Disc.iso / Samples / Moofwars 1.02 / MoofWars Encoder / Read Me First < prev   
Encoding:
Text File  |  1998-08-10  |  3.9 KB  |  66 lines  |  [TEXT/R*ch]

  1. MoofWars Encoders 8/10/98
  2. ========================
  3.  
  4. Written by Timothy Carroll
  5. timc@apple.com
  6.  
  7. Copyright © 1996,1997, 1998 Apple Computer, Inc., All Rights Reserved
  8.  
  9.  
  10. You may incorporate this sample code into your applications without restriction, though the sample code has been provided "AS IS" and the responsibility for its operation is 100% yours.  However, what you are not permitted to do is to redistribute the source as "DSC Sample Code" after having made changes. If you're going to re-distribute the source, we require that you make it clear in the source that the code was descended from Apple Sample Code, but that you've made changes.
  11.  
  12.  
  13.  
  14. WARNING
  15. =======
  16.  
  17. By default, I compile with debugging turned on, so make sure you have MacsBug installed!!
  18.  
  19.  
  20. What is it?
  21. ===========
  22.  
  23. This is a simple set of utilities that I use to compile the various sprites to add to my MoofWars games.  It leverages off of the same TGraphic classes, but also provides a few additional utilities.
  24.  
  25. There are four utilities:
  26.  
  27. Convert ICL8s, PICTs
  28. --------------------
  29. By default, you can just include PICTs or ICL8s and MoofWars will load them just fine.  The only problem with this is that compiling 100+ sprites can take a long time.  These functions write out a resource file with the sprites precompiled for fast launches.
  30.  
  31. Input:  A resource file with a color table (resource 128) and any number of PICTs or ICL8s.  PICTS must be in "triple" format -- see below.  
  32. Output: A resource file with the same color table, and a complete set of triple and graphic resources, one per input.
  33.  
  34.  
  35. Convert PICTS to Triples
  36. ------------------------
  37. The normal format for a PICT is three images side by side -- the image, the drawing mask, and the hit testing mask.  This allows some areas of a sprite to be drawn but not be affected by shots -- such as exhaust.  This routine takes a set of PICTs and converts them to the "triple" format.  The two masks generated are identical, although they could be edited later in any painting program.  The color value in the upper left corner of the input PICT is assumed to be the chroma-key color, and anything within a certain distance of that color is assumed to be "transparent" and is not included in the mask.
  38.  
  39. Input:  A resource file with a color table (resource 128) and any number of PICTs.
  40. Output: A resource file with the same color table, and a complete set of triple picts.
  41.  
  42.  
  43. Encode a Tile Grid
  44. ------------------
  45.  
  46. The GRID resource allows any tile to be shown in any position in the grid.  This function just generates a sample tile and grid, based on a picture.
  47.  
  48. Input:  A resource file with a color table (resource 128) and a single PICT (resource 128)
  49. Output:  The PICT is diced up into as many 32x32 tiles as can be created.  A single TILE resource (ID 500) is created with the tile data for each of these tiles.  A single GRID resource (ID 500) is created to generate a 44x44 playing area that repeates the PICT throughout the playing area.
  50.  
  51. Most of the values (resource IDs, sizes of the grids, and so on) are stored in constants that can be adjusted.  Time permitting, I may try to write a true GRID editor that lets you graphically make any number of tiles and paint a grid with them.
  52.  
  53.  
  54. Future Development
  55. ==================
  56.  
  57. Beyond making the tools a little more flexible, the biggest thing I'll probably add is some standard mac interface stuff, such as progress bars, error dialogs and so on.  Right now, the only way to know what errors appear is to run the debugging version.  (Which was fine for me because this is a development tool, not a user-level tool).
  58.  
  59.  
  60. Feedback
  61. ========
  62.  
  63. I've tried to make this code bug-free, easy to understand, and most importantly, FAST!  So if the code fails in any of these areas, please drop me a line and tell me exactly what you ran into.  (Ideally, run the debugging version and tell me where it stops).
  64.  
  65. Performance isn't quite as important for these tools, but if you hit a performance snag, let me know and I'll fix it.
  66.